01 AI Agent基础知识面试题

在这个Agent AI 面试题系列文章，我系统整理了一套AI Agent 面试题体系，帮助你从零搞懂 Agent 的核心概念、LangChain与LangGraph用法以及工程实现方式。

1、什么是 AI Agent？

AI Agent 是一种以目标为驱动，利用大语言模型（LLM）进行推理和决策，通过调用工具（Tool）与外部环境交互，并结合记忆（Memory），进行逻辑循环，直到完成任务的智能系统。

在LangChain的官网将Agent定义为：Agent=Model + Harness

其中Model就是指LLM大语言模型，Harness可以理解为让LLM真正能干活的一套运行框架，包含工具调用、记忆管理等功能，单纯使用Prompt+Model只具备推理能力，而LLM+Harness才是一个真正又能思考、又能行动的AI Agent智能体。

2、Agent 和普通聊天机器人的区别是什么？

AI Agent与传统 ChatBot 最大的区别在于：

• ChatBot：只能根据提示词生成对应的答案。
• Agent：能够根据提示词，自主执行任务。

一个AI Agent的执行流程如下：

例如用户要求："帮我整理最近一周AI Agent领域的重要新闻并发送到邮箱“，ChatBot只能告诉用户怎么做，而Agent可以自主完成：

3、Agent 的核心模块有哪些？

一个完整的 AI Agent 通常由以下五个部分组成：

（1）大语言模型（LLM）

Agent 的"大脑"，负责理解用户意图、进行推理、做出决策。LLM 的能力上限基本决定了 Agent 的能力上限。

（2）工具（Tools）

工具是Agent 的"手脚"，LLM 本身只能生成文本内容，但通过工具可以与外部世界交互，比如：联网搜索、代码执行器、API调用、文件读写等。

（3）记忆（Memory）

LLM作为Agent的大脑，它本身不具备记忆能力，在和Agent对话的过程中，需要把过往的历史记忆信息一并传递给LLM，才能让Agent拥有记忆。

目前，Agent 的记忆系统分为两种：

• 短期记忆：当前对话的上下文，比如和LLM对话最近的十条消息。
• 长期记忆：持久化存储的信息，比如用户偏好，对话主题，长期记忆可以通过LLM对短期记忆进行总结，每次生成新的长期记忆。

（4）规划能力（Planning）

当Agent在面对复杂任务时，Agent 要把一个大目标拆解成多个小步骤，按计划逐步完成。

例如：

帮我做一个xxx竞品分析

Agent会制定计划：

1. 搜集竞品
2. 分析功能
3. 分析价格
4. 生成报告

（5）推理能力（Reasoning）

推理能力决定下一步Agent应该做什么，比如是否调用、调用哪个工具。

4、什么是 ReAct？

ReAct（Reason + Act）是一种 Agent 执行范式，通过“推理（Thought）→ 行动（Action）→ 观察（Observation）”的循环

让大模型能够自主决定何时调用工具、如何调用工具，以及如何利用工具结果继续推理，最终完成复杂任务。它是当前大多数 Agent 框架的基础思想之一。

Thought（推理） → Action（行动） → Observation（观察） → Thought（推理） → Action（行动） → Observation（观察） → ... → Final Answer（输出最终结果）

5、举例说明ReAct 的执行流程是什么？

假设用户问："杭州今天的天气怎么样？"

Thought: 用户想知道杭州今天的天气，我需要调用天气查询工具
Action: 调用天气API，生成参数：城市=杭州，日期=今天
Observation: 杭州今天晴，气温 22-30°C，湿度 65%

Thought: 我已经拿到了天气数据，可以直接回答用户了
Action: 不需要再调用工具
Final Answer: 杭州今天天气晴朗，气温22到30度，湿度65%，比较适合出行。

整个过程中，LLM 先推理出需要做什么，再选择工具执行，拿到结果后进行观察，再继续推理，判断不需要调用工具后，直接给出最终答案。

6、ReAct 有哪些缺点？

ReAct 虽然简单直观，但在实际使用中会遇到几个问题：

（1）容易死循环

LLM 可能在 Thought → Action → Observation 之间反复循环，始终无法输出最终结果，消耗大量 token，可以限制循环次数来避免死循环。

（2）长任务容易丢失上下文

对于复杂任务，ReAct 会不断把 Thought → Action → Observation追加到上下文中，会造成token消耗增加、处理速度下降、模型注意力分散等问题。

（3）缺少全局规划

这是ReAct最核心的缺陷之一，ReAct 本质上是"走一步看一步"，边想边做，没有全局的计划。在处理一些多步骤的复杂任务时，容易执行混乱或者遗漏步骤。

（4）token 消耗大

ReAct每执行一步都要让LLM思考一次，调用LLM的次数就会成倍增加，会造成大量token的消耗。

（5）执行速度慢

因为ReAct整个循环是串行执行，等到上一次工具调用结果返回，才能再次思考和调用工具，执行速度就会显得很慢。

（6）工具的选择不稳定

由于工具的选择是交给LLM的，因此工具的选择就具有不确定性，可能同一个问题每次调用的工具却不相同，比如这次用Google搜索工具，下次可能用Baidu搜索工具。

7、什么是 Plan-and-Execute？

Plan-and-Execute 是在 ReAct 基础上发展出来的一种 Agent 设计模式，它的核心思想是：先制定完整计划，再按计划执行。

Plan-and-Execute整个流程分为两个阶段：

（1）规划阶段：LLM 先把用户的任务拆解成一个有序的计划列表，比如：

任务：帮我分析竞品并生成报告

计划：
1. 搜索竞品A的公开信息
2. 搜索竞品B的公开信息
3. 对比分析两者的优劣势
4. 生成分析报告
5. 发送邮件

（2）执行阶段：按照计划列表，依次执行每一步。每完成一步，可以选择是否需要调整后续计划。

8、Plan-and-Execute 和 ReAct 的区别？

通过开车这件事来比喻 Plan-and-Execute 和 ReAct 的区别：

ReAct：开车每开出10m，停下来继续规划路线，效率低下。

Plan-and-Execute：在出发前，先用导航规划好起点到终点的路线，再开车，效率更高

以下是在各个维度对比 ReAct 和 Plan-and-Execute 的差异

对比维度	ReAct	Plan-and-Execute
执行策略	走一步看一步	先规划，再执行
适合场景	简单任务，步骤少	复杂任务，步骤多
出错恢复	一步出错后，后续错的越来越离谱	可以根据执行结果动态调整计划
token 消耗	每轮都要带完整历史	规划阶段和执行阶段分离，相对可控

实际开发中，两种方式经常会结合使用：用 Plan-and-Execute 做全局规划，每一步执行时用 ReAct 来处理细节。

9、什么是 Reflection Agent？

Reflection Agent（反思型 Agent）是指Agent在完成任务后，不会直接把结果丢给用户，而是进行自我检查和改进，输出反思、优化后的结果。

整个过程可以理解为：

任务执行 → 回顾/检查 → 自我修正 → 再执行/优化 → 输出

Reflection 通常和 Plan-and-Execute、ReAct 结合使用：Plan-and-Execute 负责全局规划，ReAct 负责执行细节，而 Reflection 进行结果反思并进行优化。

10、Reflection 解决什么问题？

Reflection 主要解决 Agent 一次性生成结果质量不稳定、执行过程中无法自我纠错的问题。

在实际生产中，Agent很容易出现以下问题：

(1) 工具使用错误：调用工具错误或者调用顺序错误

(2) 输出结果不符合要求

(3) 复杂问题遗漏步骤

Reflection 通过”执行→检查→修正”的闭环机制，能有效提高复杂任务的输出质量。

总结一下，以上三种Agent设计模式：ReAct 解决“怎么做”，Plan-and-Execute 解决“做什么”，Reflection 解决“做得对不对”。

11、什么情况下用单Agent？

当满足以下场景，更加适合使用单 Agent：

（1）任务目标明确

用户的需求很明确，不需要多个领域协作。比如：天气预报查询、知识库问答、代码生成等场景

（2）任务链路较短

任务的执行流程比较简单，基本就是一条直线走下去，不需要太多的分支判断。

（3）工具数量不多

用到的工具数量不多，LLM很容易判断应该在什么时候调用什么工具，以及如何调用。

（4）角色单一

不需要明显的角色分工，比如产品经理、程序员、测试工程师等等。

12、什么情况下用多Agent？

以下场景适合用多 Agent：

（1）需要角色分工

比如让一个 Agent 负责搜集资料，另一个 Agent 负责撰写文案，第三个 Agent 负责审核校对。就像一个团队，每个人有明确的分工。

（2）任务之间有并行关系

有些子任务可以同时进行，多 Agent 可以并行执行，提高效率。

（3）上下文过大

比如在分析一个大型项目源代码时，一个Agent的上下文明显不够，就按模块拆分，让不同的Agent去分析不同的模块。

（4）不同模型擅长执行不同任务

比如 GPT 擅长推理，Claude 擅长写代码，Gemini 擅长图片生成，就可以使用多Agent让不同Agent负责不同的模块。

13、多Agent一定比单Agent好吗？

不一定。 多 Agent 引入了更多的复杂性，很多情况下反而不如单 Agent：

Multi-Agent 的优势在于角色分工、并行处理和复杂任务协作，但同时会带来以下问题：

（1）更高的成本：多Agent调用LLM次数增加，进而增加成本

（2）更长的延迟：每个Agent进行推理、结果生成、传递信息，系统响应明显变慢

（3）更复杂的调试：当出现问题时，排查是哪个Agent出现问题会很困难

（4）Agent 间通信损耗：Agent之间靠文本传递信息，可能会丢细节。

在实际项目中，通常遵循“先单 Agent，后 Multi-Agent”的原则：当单 Agent 能够完成任务时优先保持简单，只有在任务复杂度、上下文规模或协作需求达到一定程度时，才引入 Multi-Agent 架构。

14、Agent 和 Workflow 的区别是什么？

Workflow 是由开发者预先定义好的执行流程，步骤和路径基本固定；而 Agent 则依赖LLM进行动态决策，根据当前状态自主选择下一步行动。

Workflow 具有稳定、可控、易调试的特点，适合规则明确的业务流程；

Agent 具有灵活、自主和适应复杂任务的优势，但成本和不确定性更高。

在实际项目中，通常会将 Workflow 和 Agent 结合使用，用 Workflow 管理整体流程，用 Agent 处理需要LLM决策的环节。

15、哪些业务场景根本不适合 Agent？

Agent 虽然强大，但并不是所有场景都适合用：

（1）对准确性要求极高

比如金融交易、医疗诊断这类领域，LLM 有可能出现幻觉或做出错误判断，一旦出错后果严重。

（2）简单的 CRUD 操作

如果业务逻辑就是增删改查，完全不需要 Agent。用传统的 Web 框架就能搞定，引入 Agent 只会增加复杂度和成本。

（3）实时性要求高

Agent 每做一步决策都要调用 LLM，响应时间通常在几十秒甚至更长时间。如果业务要求实时性很高，Agent不适合这种场景。

（4）流程固定

在任务执行时，每一步做什么、怎么处理都已经很明确了，用 Workflow 比用 Agent 更合适、更可控。

（5）数据敏感性强

Agent 在执行过程中可能会把敏感数据传输给 LLM，如果对数据安全有严格要求，不适合使用开放的大模型，可以自行本地部署大语言模型，这样可以保证数据不外流。

16、在 Agent 的设计中，"规划能力"至关重要。请谈谈目前有哪些主流方法可以赋予 LLM 规划能力？（例如 CoT, ToT, GoT等）

目前常见的 LLM 规划方法主要有以下几类：

（1）CoT（Chain of Thought，思维链）

CoT 是最基础的规划方式，核心思想是让模型不要直接给答案，而是先一步一步推理。

例如：

问题 → 分析步骤1 → 分析步骤2 → 分析步骤3 → 最终答案

在 Agent 中，CoT 可以帮助模型把复杂问题拆成多个中间步骤，提高推理过程的稳定性。

（2）ToT（Tree of Thoughts，思维树）

ToT 可以理解为 CoT 的升级版。CoT 通常是一条线性推理路径，而 ToT 会同时生成多条可能的推理路径，再对这些路径进行评估和选择。

例如：

目标
├── 方案A → 评估
├── 方案B → 评估
└── 方案C → 评估

ToT 更适合需要搜索、比较和决策的复杂任务，比如数学推理、策略规划、代码方案选择等。

（3）GoT（Graph of Thoughts，思维图）

GoT 进一步打破了树形结构的限制，把推理过程建模成图结构。不同的思考节点之间可以相互连接、合并和复用。

它适合处理非线性复杂任务，比如多个子问题之间相互依赖、需要反复修正和汇总的场景。

（4）Plan-and-Execute

先由 LLM 生成完整计划，再由 Agent 按计划逐步执行。它可以减少 ReAct 走一步看一步的问题，让任务执行更有全局性。

（5）ReAct

ReAct 本身也具备一定规划能力，只不过它的规划是局部规划：每一步根据当前观察结果决定下一步行动。

总结来说：

• CoT：让模型一步一步想。
• ToT：让模型同时比较多条思路。
• GoT：让模型用图结构组织复杂思路。
• Plan-and-Execute：让模型先规划再执行。
• ReAct：让模型边观察边行动。

17、在构建一个复杂的 Agent 时，你认为最主要的挑战是什么？

构建复杂 Agent 最大的挑战不是让 LLM 调用工具，而是如何让整个系统稳定、可控、可观测地完成任务。

主要挑战包括以下几个方面：

（1）任务规划不稳定

复杂任务往往需要拆解成多个步骤，但 LLM 生成的计划可能不完整、不合理，甚至遗漏关键步骤。

（2）工具调用不可靠

Agent 需要判断什么时候调用工具、调用哪个工具、参数如何生成。如果工具描述不清楚，或者模型理解错误，就可能调用错误工具或传入错误参数。

（3）上下文管理困难

复杂任务执行时间长，过程中会产生大量中间结果。如果全部放进上下文，会造成 token 消耗过大；如果压缩或丢弃上下文，又可能丢失关键信息。

（4）错误恢复能力弱

真实环境中工具调用可能失败、接口可能超时、数据可能不完整。Agent 需要能够识别错误、重试、调整计划，而不是一直沿着错误方向执行。

（5）结果质量不可控

LLM 输出具有不确定性，同一个任务多次执行可能得到不同结果，因此需要增加校验、评估、反思和人工确认机制。

（6）调试和观测困难

Agent 的执行链路通常包含多轮推理、工具调用、状态变化和记忆更新。如果没有完整日志，很难定位问题到底发生在规划、工具调用还是模型输出阶段。

所以，复杂 Agent 工程化的核心是：规划要清晰，工具要可靠，状态要可追踪，错误要可恢复，关键节点要可人工干预。

18、当一个 Agent 需要在真实或模拟环境中（如机器人、游戏）执行任务时，它与纯粹基于软件工具的 Agent 有什么本质区别？

本质区别在于：环境型 Agent 需要感知和影响一个动态环境，而软件工具型 Agent 主要是在确定的 API 或工具之间进行调用。

主要区别包括：

（1）输入来源不同

软件工具型 Agent 的输入通常是文本、结构化数据或 API 返回值；而机器人、游戏 Agent 的输入可能来自摄像头、传感器、地图、游戏状态等多模态信息。

（2）动作空间不同

软件工具型 Agent 的动作通常是调用搜索、数据库、代码执行器、邮件等工具；环境型 Agent 的动作可能是移动、抓取、跳跃、攻击、转向等物理或模拟动作。

（3）环境是动态变化的

软件工具调用通常是一次请求一次响应，相对静态；真实或模拟环境会持续变化，Agent 当前动作会影响下一刻的环境状态。

（4）容错成本不同

软件工具 Agent 调错了 API，通常可以重试或回滚；机器人在真实世界中执行错误动作，可能造成设备损坏或安全风险。

（5）需要闭环控制

环境型 Agent 不是简单地“思考一次、调用一次工具”，而是需要持续执行：

感知环境 → 决策动作 → 执行动作 → 观察反馈 → 调整策略

因此，环境型 Agent 通常需要结合强化学习、规划算法、视觉模型、控制系统等能力，而不仅仅是 LLM 工具调用。

19、什么是多智能体系统？让多个 LLM Agent 协同工作相比于单个 Agent 有什么优势？又会引入哪些新的复杂性？

多智能体系统是指由多个 Agent 组成的协作系统，每个 Agent 可以拥有不同的角色、目标、工具和记忆，通过通信与协作共同完成任务。

例如，一个代码开发多 Agent 系统可以这样分工：

• 产品 Agent：分析需求
• 架构 Agent：设计方案
• 编码 Agent：实现功能
• 测试 Agent：编写并执行测试
• Review Agent：检查代码质量

相比单 Agent，多 Agent 的优势包括：

（1）角色分工更清晰

不同 Agent 可以专注不同任务，类似真实团队协作。

（2）并行处理能力更强

多个 Agent 可以同时处理不同子任务，提高复杂任务的执行效率。

（3）上下文压力更小

每个 Agent 只需要维护自己负责领域的上下文，不必把所有信息都塞进一个模型窗口。

（4）可以相互审查

一个 Agent 生成结果后，另一个 Agent 可以进行检查、质疑和修正，从而提高结果质量。

但多 Agent 也会引入新的复杂性：

（1）通信成本增加

Agent 之间需要传递信息，如果通信内容过长，会增加 token 成本；如果过短，又可能丢失关键信息。

（2）协调难度增加

多个 Agent 可能产生冲突意见，需要有调度者或仲裁机制来决定最终方案。

（3）链路更难调试

当最终结果出错时，需要判断是哪个 Agent 的规划、执行或通信出了问题。

（4）成本和延迟更高

多个 Agent 意味着更多 LLM 调用，系统成本和响应时间都会上升。

因此，多 Agent 并不是越多越好。实际项目中通常优先使用单 Agent，只有在任务确实需要角色分工、并行处理或上下文拆分时，才引入多 Agent。

20、有微调过Agent能力吗？数据集如何收集？

可以从两个层面回答：如果是面试中被问到，可以说明自己是否真正做过；如果没有完整微调经验，也可以讲清楚 Agent 微调通常怎么做。

Agent 能力微调的目标不是让模型记住知识，而是让模型更稳定地学会：

• 如何理解任务
• 如何拆解步骤
• 如何选择工具
• 如何生成工具调用参数
• 如何根据工具返回结果继续推理
• 如何在失败时修正策略

数据集通常可以从以下几个来源收集：

（1）真实 Agent 运行日志

记录用户请求、模型思考过程、工具调用、工具返回结果、最终回答等完整轨迹。

例如：

User Query → Thought → Tool Call → Observation → Final Answer

这类数据最贴近真实业务场景，价值最高。

（2）人工标注数据

由人工构造任务，并标注正确的任务拆解步骤、工具选择、参数格式和最终答案。

适合用来提高模型在关键业务流程中的稳定性。

（3）合成数据

使用能力更强的模型生成 Agent 执行轨迹，再经过人工筛选和清洗。比如让强模型生成 ReAct 格式数据、工具调用样本、多轮任务执行样本。

（4）失败样本和修正样本

收集 Agent 调用错误工具、参数错误、答案不符合要求等失败案例，再标注正确修正过程。这类数据对提升 Agent 的自我纠错能力很有帮助。

数据格式一般包含：

{
  "instruction": "帮我查询杭州今天的天气，并给出穿衣建议",
  "tools": ["weather_api"],
  "trajectory": [
    {"thought": "需要查询杭州天气"},
    {"tool_call": "weather_api", "arguments": {"city": "杭州"}},
    {"observation": "杭州今天晴，22-30°C"},
    {"answer": "杭州今天晴，适合穿短袖，建议防晒。"}
  ]
}

在工程实践中，不一定一开始就做微调。通常会先通过 Prompt、工具描述、工作流约束、RAG 和评估集优化 Agent。当这些方式仍无法满足稳定性要求时，再考虑微调。

21、了解Transformer吗？

了解。Transformer 是当前大语言模型的核心基础架构，最早来自论文《Attention Is All You Need》。它的核心思想是使用 Self-Attention（自注意力机制） 来建模序列中不同 token 之间的关系。

传统的 RNN、LSTM 需要按顺序处理文本，而 Transformer 可以并行处理整个序列，因此训练效率更高，也更适合大规模预训练。

Transformer 的核心组成包括：

（1）Token Embedding

把输入文本切分成 token，并映射成向量表示。

（2）Position Encoding（位置编码）

由于 Transformer 本身不像 RNN 那样天然具备顺序信息，所以需要加入位置编码，让模型知道每个 token 在序列中的位置。

（3）Self-Attention（自注意力机制）

Self-Attention 用来计算一个 token 和其他 token 之间的关联程度。

它会为每个 token 生成三个向量：

• Q（Query）
• K（Key）
• V（Value）

通过 Q 和 K 计算注意力权重，再用权重加权 V，得到当前 token 的上下文表示。

简单理解就是：模型在理解一个词时，会动态关注句子中和它最相关的其他词。

（4）Multi-Head Attention（多头注意力）

多头注意力就是并行使用多组 Attention，让模型可以从不同角度理解上下文关系。

比如有的注意力头关注语法关系，有的关注指代关系，有的关注语义关系。

（5）Feed Forward Network（前馈神经网络）

每一层 Attention 后面都会接一个前馈网络，用来进一步非线性变换和提取特征。

（6）Residual Connection 和 LayerNorm

残差连接可以缓解深层网络训练困难的问题，LayerNorm 用来稳定训练过程。

在大语言模型中，常见的是 Decoder-only Transformer 架构，例如 GPT 系列。它通过预测下一个 token 的方式进行训练：

给定前面的 token → 预测下一个 token

总结来说，Transformer 之所以重要，是因为它用自注意力机制高效建模长文本依赖，并且可以大规模并行训练，是 GPT、Claude、Gemini 等现代大语言模型的基础。